So today is the last lecture.

Alright.

Hooray.

So today we'll talk about some future ideas about what is going on in programming languages

that we're seeing now.

It'll be not the most recent, but some trends that we can identify for programming languages.

So what can we see in the future?

We'll probably see more abstraction.

But how do we achieve that next level of abstraction so that everybody can understand everything

in a program?

Alright, that is fairly tricky.

What is, for example, going on is to add more abstraction, go towards more domain-specific

languages.

Because if you're programming physics, you want to think in terms of physics and then

achieve a level of abstraction by removing anything that is not physics-related.

Anything internal to an implementation can be abstracted away from.

Documentation is, of course, also important, right?

How do we add documentation to a program, right?

In such a way that when you change the code of your program, that the documentation is

also changed automatically at the same time.

Another, there are new ways of thinking about how to construct programs.

We talked a little bit about, a lot about this for the last few lectures.

For example, component-based programming.

Communication, parallel programming.

Let's get started.

So one way of thinking about documentation is that documentation and code should not

be too far apart.

So you should not write two documents where you have the code of your program and documentation

of your program completely separate.

Because these can drift apart, right?

You change the code, but you forget to update the documentation.

This is a very common problem.

Or you update the documentation.

Of course, there's a documentation team who is separate from the programming team.

The documentation team adds documentation without knowing what the code is doing at

all.

So these are things that are actually happening.

For example, in big companies, you have a separate documentation team.

And they document what they think the program should do without looking at the actual code.

The only thing that they are reading is the requirements documents from another team.

So there are now three teams at play.

The requirements, overall design team, the documentation team, who are sometimes looking

at what the tests are doing.

You have a testing team who writes the tests, who do not talk to the documentation folks

and who do not talk to the implementation folks.

And then you have the implementation team who are doing their best at implementing the

requirements.

And all of these teams are loosely coupled.

And how do we make a better development environment?

One way of doing this is, for example, by integrating documentation and coding in one